We aren't back porting this right?
(Is the plan to wait till no more 1.5.x releases, then merge before 2.0?)

We aren't back porting this right? (Is the plan to wait till no more 1.5.x releases, then merge before 2.0?)

I think we could just apply the same change to 1.5.x, so:

git checkout -b backport-force-single-line
git fetch upstream
git reset --hard upstream/1.5.x
sed -i 's/force_grid_wrap = 2/force_single_line = true/g' pyproject.toml 
pre-commit run isort -a
git commit -a -m 'force single line = true' --no-verify

Or waiting until there's no more 1.5.x releases would be fine too

Agree, don't want to do this on 1.5.x. Lets wait till we are through there

sure, marking as draft til then

Would it make sense to replace isort with reorder_python_imports? I believe we would get the same style but benefit from reorder_python_imports's import re-writing.

reorder-python-imports doesn't support Cython files, so I don't think we could/should use it (yet)

Does isort allow us to undo this if we ultimately want to revert? +/-0 on this but feels a bit strange since a user wouldn't naturally write or read code this way

This pull request is stale because it has been open for thirty days with no activity. Please update and respond to this comment if you're still interested in working on this.

Does isort allow us to undo this if we ultimately want to revert? +/-0 on this but feels a bit strange since a user wouldn't naturally write or read code this way

We could just remove the option, and then it would go back to how it was before

Do users often write or read imports anyway though? I think most contributors just put the import somewhere at the top and then just let isort take care of where and how to place it

@mroeschke @lithomas1 thoughts on getting this in before the RC?

Exact commands I ran to do this:

1. git fetch upstream && git reset --hard upstream/main && sed -i 's/force_grid_wrap = 2/force_single_line = true/g' pyproject.toml && pre-commit run isort --all-files; git commit -a -m 'force single line = true' --no-verify (this is the first commit)
2. pre-commit run ruff --all-files (I then manually fixed up a handful of missing noqas - this is the second commit)
3. git ls-files | xargs sed -i 's/from pandas import _testing as tm/import pandas._testing as tm/g' (this is the third commit)

The third commit was to fix this unwanted pattern

which, given the current import style, wasn't actually being caught most of the time

IMO I don't think this should go into the RC yet. Since this is a style change that touches a lot of files, I think there should be a few more positive responses before committing to this.

The goal here is to remove merge conflicts (in the longer term).

Of course while there are backport branches active with these changes this would increase the probability of a merge conflict.

So probably best to do it now (and also apply the change script to 2.0.x now separately) since perhaps it should have been done before the rc.

If we need to do another 1.5.x release then we would maybe have a few merge conflicts to resolve.

I am generally +1 on this change.

I am generally +1 on this change.

Thanks!

Gonna do a @pandas-dev/pandas-core ping then to hear people's opinions

Motivation for why to do this is to further reduce merge conflicts, see #50274 for a concrete example of how it would help

Gonna do a @pandas-dev/pandas-core ping then to hear people's opinions

I find this style really un-natural from a coding standpoint. Using VSCode, imports are sometimes automatically inserted at the top. I understand the motivation. So I'm -1 on it, because it makes the imports look "noisy", but won't stand in the way.

Wondering if a solution is to resolve merge conflicts in backports by round-tripping through this idea. In other words, we keep the style as it currently is, and then when merging, convert the target to this style and the part being merged to this style, do the merge, and then convert the merged part back to the existing style. Not sure if this idea is even feasible.

Using VSCode, imports are sometimes automatically inserted at the top.

Not sure what you mean, sorry - what's the issue with that? You'll need to run isort/pre-commit anyway

I would also say it looks unnatural and I'm not aware of any human writing style that adopts this.

Do you have a sense as to how often this would reduce/avoid merge conflicts?

It feels like it would roughly on par, in terms of avoiding merge conflicts, as something like

from lib import (
    a,
    b,
    c,
)

which is already in use in lots of places.

I give an example here: #50274 (comment) . I haven't counted how often this happens, but I opened the issue after having to manually fix imports in several backports when the conflict was just due to going from a single import to multiple

which is already in use in lots of places.

It's in place everywhere - the issue is in going from

from lib import a

to

from lib import (
    a,
    b,
)

Perhaps a less unnatural-looking alternative would be to use force_grid_wrap = 1, which would force

from lib import (
    a,
)

even for single imports. I'll open a separate PR to demonstrate that

EDIT: here it is: #51693

Using VSCode, imports are sometimes automatically inserted at the top.

Not sure what you mean, sorry - what's the issue with that? You'll need to run isort/pre-commit anyway

I'm not sure of a specific example, but there are times where I'm writing code where I use something that has no import statement, and VSCode automatically creates the import statement in the right place at the top of the file. Having said that, you're correct that isort/pre-commit would fix that up automatically.

ew, gross.

The pain point for merge conflicts is in the whatsnew. id love to see a tool for that. (Also for filling in an issue reference when i dont know the number until i open a pr)

the whatsnew conflicts are orthogonal- but I agree, it would be good to address those too

ew, gross.

😆 not sure why people don't like this style, but OK, I don't want to force it. Would you be OK with #51693 instead?

closing in favour of #51693, which looks like it might have a non-zero chance of passing

(Also for filling in an issue reference when i dont know the number until i open a pr)

here you go https://ichard26.github.io/next-pr-number/